fix(cli): reload MCP config after project selection - #966

This looks like the stronger fix for #957 because the regression test exercises the actual activateProject() flow and verifies that the selected project's MCP server reaches the base agent definition.

PR #973 appears to address the same root cause with overlapping changes. Before merging, could we confirm that this PR also clears every derived local-agent cache that depends on the previous cwd/project root? If yes, I would suggest merging #966 and closing #973 as a duplicate to avoid two competing fixes.

Thanks for catching this. The local agent registry has two derived caches that depend on the previous working directory: cachedAgentsByMode and cachedAgentsDir. The new reloadLocalAgentRegistry() helper clears both before initializeAgentRegistry() refreshes the agent definitions, file paths, and MCP configuration.

I also expanded the regression test to warm the caches in the launch project, switch projects through activateProject(), and verify that the selected project supplies the agent directory, local agent list, MCP server, and base agent definition. The old project's agent must no longer be present.

Validation on the new head (2f246ab):

• 41 related tests passed
• CLI typecheck passed
• Freebuff Windows binary build passed
• 5 --version and --help E2E tests passed
• Prettier and git diff --check passed

This incorporates the cache-reset part of #973 while keeping the project-picker coverage in this PR.

Perfect, thanks for the thorough follow-up. Clearing both cwd-dependent caches and testing the full activateProject() transition addresses the concern. The added assertion that the old project's agent is absent is especially valuable.

This now seems like the right PR to merge for #957. I’d suggest closing #973 as a duplicate once a maintainer has reviewed this update.

Good catch and clean fix. The root cause is real: handleProjectChange in cli/src/index.tsx previously called setProjectRoot/resetCodebuffClient but never re-scanned .agents/ for the newly selected directory, so cachedAgentsDir/cachedAgentsByMode in local-agent-registry.ts kept serving the launch directory's MCP config. Wrapping the chdir/setProjectRoot/registry-reload/reset sequence into a single activateProject() helper in project-picker.ts is a sensible consolidation and removes the duplicated logic from index.tsx.

The added test in project-picker.test.ts is a genuine regression test — it writes real .agents/*.ts and mcp.json files into temp launch/project directories, calls activateProject, and asserts the base agent definition picks up the new project's MCP server while dropping the launch project's local agent. That's exactly the kind of test this bug needed.

Two things worth double-checking before porting:

1. reloadLocalAgentRegistry only clears cachedAgentsByMode and cachedAgentsDir — please confirm there isn't a third cache (e.g. for MCP servers specifically, or directory-scan results) elsewhere in local-agent-registry.ts that also needs clearing, since getLoadedMCPServers() presumably reads from one of these.
2. The hasAgentOverride skip path (reloadAgentRegistry: !hasAgentOverride) isn't exercised by the new test — a second test case confirming the override path doesn't reload would strengthen this further, though the existing description of preserving that behavior is plausible from the diff.

No forbidden paths touched, no scope creep — solid, focused bug fix.

Both checked.

On the first one, there is no third cache. The module keeps five mutable ones: userAgentsCache, userAgentFilePaths and mcpServersCache at the top, and cachedAgentsDir and cachedAgentsByMode further down. initializeAgentRegistry() reassigns the first three on both the success and the failure path, including mcpServersCache from loadMCPConfigSync(), which reads the cwd, so getLoadedMCPServers() is covered as long as the chdir happens first. That is why reloadLocalAgentRegistry() only clears the other two: they are derived and nothing else resets them. __resetLocalAgentRegistryForTests lists all five, which is a handy way to confirm the count did not grow.

On the second one, you were right that the skip path had no coverage. Added a test for it: with { reloadAgentRegistry: false } the chdir and project root still move, and the launch project's agent is still the one served. I checked it is worth something by making activateProject reload unconditionally, and the new test is the only one that fails.